개요

이번에는 프로메테우스와 그라파나를 활용해 모니터링하는 방법을 알아본다.
이때 나오는 메트릭들 정보를 보면서 실리움에서 어떤 메트릭들을 노출해주는지, 신경 쓸 만한 메트릭이 무엇이 있는지 간략하게 탐구하고자 한다.

실습은 이전 문서에 이어서 진행한다.
이전에 프로메테우스 메트릭을 노출하는 세팅을 이미 했기 때문에 따로 세팅하지는 않겠다.

먼저 실리움에서는 프로메테우스 메트릭 형식으로 데이터를 노출시키는 설정을 할 수 있다.
이때 크게 세 가지 영역의 메트릭을 설정할 수 있다.

• Cilium
  • 실리움 에이전트, 엔보이(L7 관련)에 대한 메트릭을 수집할 수 있다.
  • 엔보이를 위해 추가적으로 헤드리스 서비스를 배포해준다.
  • 헬름에선 prometheus.enabled=true로 설정
• Cilium Operator
  • 오퍼레이터를 추적해 클러스터에 적용된 실리움의 전반적인 상태를 확인할 수 있다.
  • 헬름에선 operator.prometheus.enabled=true로 설정하며, 활성화가 기본^[1]
• Hubble
  • 실리움으로 인해 발생하는 전반적인 네트워크 흐름과 관련된 메트릭을 수집할 수 있다.
  • 자주 쓰이는 특정 프로토콜에 대한 세부 메트릭도 제공한다.
  • 헬름에선 hubble.metrics.enabled에 노출할 메트릭 리스트 작성

이 각각의 접두사가 되어 프로메테우스 메트릭으로 찾아볼 수 있으며, 이를 실습에서 확인해 볼 것이다.

사전 지식

관측가능성

클라우드 시대가 도래하며 나온 개념 중 하나가 Observability, 즉 관측 가능성이다.
관측가능성(Observability)은 프로그램 실행, 모듈의 내부 상태, 컴포넌트 간 통신에 대한 데이터를 수집하는 기능, 능력으로 정의된다.^[2]

The ability to collect data about programs' execution, modules' internal states, and the communication among components

관측가능성은 관리자가 잘 볼 수 있도록 필요한 메트릭과 각종 정보를 수집해서 내어주는 시스템의 기능이다.
흔히 모니터링과 대비하여 표현하나, 엄밀하게 대비되는 개념은 아니다.
관측가능성이란 용어는 꽤나 넓은 의미를 커버하는데, 다양한 데이터를 통해 각종 문제를 진단하고 원인 분석, 대응을 하는 일련의 작업과 툴까지도 총칭해버리기도 한다.

배경

시스템의 구조는 장애 회복력, 고가용성 등을 위해 내부의 컴포넌트들 간 종속성을 줄이고 결합도를 느슨하게 하는 방향으로 발전하고 있다.
대표적인 예시가 MSA인데, 이러한 아키텍처는 소기의 목적을 분명하게 달성하는데 도움을 주지만 되려 내부 구조를 복잡하게 만들어 다양한 문제를 야기하기도 한다.
일단 분산된 거대한 시스템 내부에서 일어나는 상황을 제대로 알기 어렵다는 것이 핵심이다.
이로 인해 어떠한 문제가 발생해도 어디에서 문제가 발생한 것인지 추적하는데 시간이 오래 걸리고, 문제라고 생각해야 할 만한 상황 자체를 탐지하는 것조차 어려워지기도 한다.

이때 시스템의 내부 상태를 좀 더 가시적으로 만들어야 한다는 수요가 생겨났고, 자연스레 관측가능성이란 개념이 떠오르게 됐다.
현대의 운영 담론에서는 모든 고장이나 문제를 사전에 알 수 없고, 고정된 기준을 두고 파악할 수 없다는 것을 가정한다.
대신 시스템으로부터 최대한 다양한 방법으로, 다양한 지표를 수집하여 정제된 형태로 시각화하는 것을 목표로 시스템에 각종 설정을 한다.
이를 통해 가급적 발생한 문제를 빠르게 탐색하고, 아울러 발생할 수도 있는 문제들을 투명하고 직관적으로 볼 수 있게 환경을 구성하는 방향으로 나아가고 있는 것이다.

이렇게 관리자가 편하게 시스템으로부터 노출되는 외부 신호와 특성만을 통해서 내부 상태를 파악할 수 있도록 하는 시스템의 속성을 관측가능성이란 용어로 표현하기 시작했다.
관측가능성이란 개념이 나온 흐름은 이 정도로 요약할 수 있을 것 같다.

• 현대 시스템은 모든 문제를 사전에 알 수 없다.
• 그래서 관리자가 각종 지표가 드러나도록 능동적으로 세팅하는 과정이 필요하다.
  • 이를 통해 시스템의 내부 상태를 쉽게 파악하여 문제를 탐색하는 것을 용이하게 한다.
• 이렇게 세팅된 시스템은 관측 가능성을 가졌다고 표현한다.

고가용성은 명확하게 수식을 정의할 수 있는 지표이나, 관측 가능성은 수치화하기 어렵다.
사실 관리자, 개발자가 필요로 하는 각종 데이터들이 회사마다 환경마다 다를 수 있고, 구축하고 세팅한 정도를 나타낸다고 해서 그게 그렇게 의미가 있는 것도 아니다.
다만 비즈니스 개념을 얹어서 MTTR(Mean Time To Recovery)를 보완하며 간접적으로 정도를 표현하는 것은 가능하겠다.

측정 대상 - 시그널

시스템에 관측 가능성을 부여하기 위해 측정(telemetry)할 만한 데이터, 혹은 요소가 무엇이 있을까?
오픈텔레메트리에서는 이러한 데이터들을 신호(signal)라고 표현한다.
현대에는 수집할 신호를 크게 3가지로 분류하고 있다.

간단하게는 지피티가 이렇게 요약하는데, 잘 설명한 것 같다.^[3]
자세한 설명은 관측 가능성을 참고하자.

프로메테우스

프로메테우스는 처음 사운드클라우드에서 만든 모니터링, 알람 시스템이다.
많은 회사들이 프메를 사용하면서 점차 관측 가능성 툴쪽에서는 거의 defacto가 돼버렸다.

프로메테우스는 여러 특징을 가지고 있다.

• 데이터를 Pull 방식으로 수집한다.
  • 즉, 중앙 서버는 각지에 설치된 익스포터가 노출하는 경로로 요청을 날려 데이터를 가져온다.
  • 중앙 서버가 경로를 노출하여 다른 곳에서 데이터를 Push 해주는 방식과는 다르기에 분산 환경에서 설정 관리에 용이하다.
• 자체로도 지표들을 확인하고 시각화할 수 있으나, 대체로 Grafana를 이용해 시각화 대시보드를 만들어 곁들여 사용한다.
• PromQL이라고 하는 데이터 쿼리 언어를 가지고 있다.
  • 이걸 잘 활용하여 유의미한 데이터를 얻어내는 것이 엔지니어링 역량 중 하나라고 할 수 있다.
  • 최소한의 기본기를 가지고 있으면 매우 도움이 되며, 관련한 자격증도 있을 정도니 잘 익혀두는 것이 좋다.
• TSDB
  • Time Series DataBase, 즉 시계열 데이터를 저장하는 저장소를 가진다.
  • 이를 통해 시간을 단위로 지속적으로 수집되는 로그, 메트릭 데이터를 효율적으로 저장한다.
  • 이 저장소는 기본적으로 동적 확장이 지원되지 않으므로, Thanos와 같은 외부 스토리지 솔루션을 사용하는 것이 추천된다.
• 동적 재설정
  • SIGHUP 시그널이나, /-/reload 엔드포인트로 요청을 날려 변경된 설정을 동적으로 넣어줄 수 있다.

몇 가지 안 좋은 특징도 가지고 있다.

• 수평 확장이 용이하지 않다.
  • 프로메테우스 서버가 동적 확장을 잘 지원하지 않는 듯하다.
  • federation이라는 기능을 제공하나, 많이 쓰이진 않는 듯.
  • 그래서 다른 서드파티 솔루션을 결국 많이 연계하게 된다.

구조

기본적으로 이런 구성으로 되어 있다.

• Prometheus server
  • 데이터를 긁어오고 저장한다.
  • TSDB를 사용하여 데이터를 효율적으로 저장한다.
• Exporter
  • 중앙 서버가 긁어갈 데이터를 노출하는 서버
  • 내가 수집하고자 하는 대상에 익스포터를 설치하면 된다.
  • 노드의 정보를 얻고 싶으면 Node Exporter, 스프링이면 Spring Exporter.. 이런 식이다.
• Service Discovery
  • 중앙 서버에서 데이터를 긁어올 곳을 동적으로 찾는 과정, 행위.
  • 일반적으로 중앙 서버에서는 데이터를 어디에서 긁어올지 직접 설정해야 한다.
  • 그러나 이 방식은 정적이고 귀찮으므로, 특정 조건을 걸어두어 그 조건에 맞게 긁어올 장소를 탐색하게 하는 기능이다.

데이터 유형과 양식에 대한 자세한 설명은 프로메테우스 참고

그라파나

그라파나는 오픈소스로 개발이 진행되는 멀티 플랫폼 분석, 시각화 웹 어플리케이션이다.
Grafana Labs에서 개발을 진행하고 있으며, 이 제품이 해당 기업의 주력 기술이다.
이 기업에서는 그라파나를 주축으로 한 그라파나 생태계를 만들고 있다.

시계열 데이터를 시각화하는데 특히 탁월하며, Prometheus 와 궁합이 좋다.
최근에는 로그 데이터를 수집하기 위해 Loki를 만들어서 함께 운영하고 있다.
이밖에도 관측 가능성으로서 정의되는 트레이스, 로그 등의 유형도 통합적으로 제공하기 위해 Mimir, Tempo까지 함께 운영하고 있다.
이들을 합쳐서 LGTM(Loki, Grafana, Tempo, Mimir) 라고 부르고 있다.

프로메테우스, 그라파나 실습

이전에 헬름을 세팅할 시 이미 설정을 완료했기 때문에 프로메테우스 메트릭을 노출하는 포트는 전부 열려 있는 상태이다.

ss -tnlp | grep -E '9962|9963|9965'

이 절에서는 적용은 가급적 간단하게 하고, 어떤 식의 지표가 있고 시각화를 활용할 수 있는지 알아본다.

kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.17.6/examples/kubernetes/addons/prometheus/monitoring-example.yaml
kubectl patch svc -n cilium-monitoring prometheus -p '{"spec": {"type": "NodePort", "ports": [{"port": 9090, "targetPort": 9090, "nodePort": 30001}]}}'
kubectl patch svc -n cilium-monitoring grafana -p '{"spec": {"type": "NodePort", "ports": [{"port": 3000, "targetPort": 3000, "nodePort": 30002}]}}'
kubectl get deploy,pod,svc,ep -n cilium-monitoring
kubectl get cm -n cilium-monitoring

kc describe cm -n cilium-monitoring grafana-config
kc describe cm -n cilium-monitoring grafana-cilium-dashboard
kc describe cm -n cilium-monitoring grafana-hubble-dashboard

프로메테우스에서는 세 가지 접두 키워드를 확인할 수 있다.

실리움에서는 다음의 대시보드를 제공해주고 있다.

대시보드 파일을 써먹고 싶다면 설치할 때 세팅된 컨피그맵에서 줍줍해가도 된다.

어느 정도 그라파나 대시보드 만지는 법과 데이터를 보는 법을 익혔기에 여기에서는 각 대시보드가 무얼 뜻하는지를 조금 중점적으로 보며 실리움 커뮤에서 보여주고자 했던 것이 무엇인지 파악하고자 한다.

대시보드 - cilium metrics

일단 노드 별로 출력을 걸어서 볼 수 있다.

가상 메모리는 Vmsize를 말하는데 실리움 프로세스가 사용한 메모리 사용량을 보여준다.

1기가가 넘어 용량이 커보이지만, go 언어는 런타임이 초반에 일부러 GC를 할 거라 메모리를 넉넉히 예약해두기도 하고 실질적으로 사용량은 더 적을 수 있다.

cilium_process_resident_memory_bytes
실제 메모리 사용중인 양은 resident 메모리를 봐야한다.

/proc/<pid>/status에서 VmRss에 해당하는 값으로, 실제 물리 메모리에 상주하고 있는 양을 나타낸다.

cilium_process_open_fds
이 지표가 치솟는 경우 주의할 필요가 있어보인다.

실리움은 BPF 동작을 하며 정책과 라우팅 등을 하기 위해 커널 객체나 프로세스(/proc) 등의 파일과 디바이스에 자주 접근한다.
하물며 관련한 연결이 필요한 다른 프로세스와는 유닉스 도메인 소켓으로 연결을 하는 경우도 많아 FD가 어느 정도 많아지는 게 흔하고 최대 개수를 넘어 문제가 생길 때 영향도가 클 수도 있다.

avg(cilium_bpf_maps_virtual_memory_max_bytes{k8s_app="cilium", pod=~"$pod"} + cilium_bpf_progs_virtual_memory_max_bytes{k8s_app="cilium", pod=~"$pod"})

BPF에서 활용하는 메모리 사용량에 대한 정보.
그런데 bpf는 대체로 어떻게 해도 시스템 전체에 영향을 줄 정도의 메모리 사용량을 가지기는 힘들고 그런 부분을 제거해야 하기 때문에, 이건 실리움 개발 측에서 주로 신경을 쓸 지표가 아닐까 싶다.

cilium_bpf_map_pressure

bpf 맵이 가득차면 nat 시 연결 추적을 실패하거나 패킷 처리가 실패하는 등의 이슈가 발생할 수 있기 때문에 부하가 심할 때 유의할 지표 중 하나이다.
헬름에서 bpfMapSize 등을 조절하며 커스텀할 수 있다.

avg(rate(cilium_agent_api_process_time_seconds_sum{k8s_app="cilium", pod=~"$pod"}[1m])/rate(cilium_agent_api_process_time_seconds_count{k8s_app="cilium", pod=~"$pod"}[1m])) by (pod, method, path)

에이전트로의 요청 레이턴시.

avg(histogram_quantile(0.90, rate(cilium_endpoint_regeneration_time_stats_seconds_bucket{k8s_app="cilium", scope!="total", pod=~"$pod"}[5m]))) by (scope)

보기가 조금 어려운데, 엔드포인트 재생성(라우팅 경로, 리소스 변화 추적, 신원 등 최신화)에 대해서 재생성 범위에 따라 걸린 시간을 보는 블록이다.
여기에서의 지연은 파드 생성이나 업데이트에 직접적인 영향을 끼치는 것이기에 대규모 클러스터에서 유의깊게 볼 필요가 있는 지표이다.

대시보드 - cilium operator

이 대시보드는 실리움 오퍼레이터가 공개하는, 오퍼레이터 자체와 클러스터 전체 관련한 일부 대시보드를 제공한다.

오퍼레이터 프로세스 자체에 대한 정보는 그렇게까지 많이 볼 것 같지 않다.
다만 IPAM, 인터페이스 정보 등은 EKS에서 활용할 때 유용할 수도 있을 것 같다.

대시보드 - hubble

허블 대시보드에서는 네트워크 트래픽 전반에 대한 정보를 다루며, 발생 건이 많은 특정 프로토콜들에 대해 추가적인 메트릭을 제공하는 것은 이용해 관련 대시보드를 제공해주고 있다.

플로우에 대한 정보를 찾으면서 각 타입에 뭐가 있는지 찾아보려했다.


이 타입들은 허블을 직접 모니터링할 때도 등장한 값들로, 이 의미를 명확히 하면 앞으로 모니터링을 할 때 도움이 될 것이라 생각했다.
근데 플로우 타입이 어떤 것들이 있는지 자료를 찾기가 어려웠다.^[4]
아쉬운 대로 일단 gpt의 도움을 받았다.

• Drop - 차단된 패킷

• L7 - 엔보이로 넘어간 패킷

• PolicyVerdict - 정책 판단 결과. allow 혹은 deny

• Trace - BPF 체인을 통과하며 발생한 중간 처리 이벤트

• Unknown

• 7 - 일반 L7 레벨 프로토콜

• HTTP - 그 중에 http 한정

• to-endpoint - 로컬 노드 내 다른 파드로 전달된 트래픽

• to-network - 노드 외부로 나간 트래픽

• to-proxy - 엔보이로 간 트래픽

• to-stack - 커널 네트워크 스택(iptables 등)으로 전달된 트래픽

이 각각이 정확하게 뭔지를 구별할 수 있는 자료를 찾으면 조금 더 최신화 하겠다.

대시보드 - hubble ly http by workload

이 대시보드는 http 트래픽에 한정하여 더 자세한 정보를 받아볼 수 있다.

허블에서 제공하는 http 관련 메트릭들을 이용하여 시각화해주기에 현재 트래픽 플로우를 추적하는 허블 ui에 더불어 전체적인 정보를 받아보는데 유용할 것으로 보인다.

결론

허블도 좋지만 따지자면 허블은 역시 키알리에 가까운 툴이라고 본다.
결국 전반적인 모니터링을 하기 위해서는 프로메테우스와 같은 다른 툴의 도움을 받는 것이 좋아보인다.
공식 문서에서도 프로메테우스 스택과의 연동에 대한 내용이 상세하게 나와있어 적극적으로 활용할 수 있을 것 같다.

한편으로 문서에서 다루는 내용 중에서는 모니터링으로 인한 성능 저하에 대한 고려도 있었다.
다음의 두 데이터는 지나치게 많이 발생하여 대규모 클러스터에서 큰 부하를 초래할 수 있기에 에이전트 명령 인자에 다음을 추가하는 것도 고려해볼만 하다고 한다.^[5]
--metrics="-cilium_node_connectivity_status -cilium_node_connectivity_latency_seconds"
마이너스를 붙이면 메트릭을 노출하지 않고, 플러스를 붙이면 노출한다.
아무튼 CNI로서 필연적으로 많은 데이터가 발생할 수밖에 없는 실리움인 만큼, 필요한 데이터만 뽑아내는 것도 중요할 것으로 보인다.

이전 글, 다음 글

• 2W - 허블 기반 모니터링: 4
• 3W - 실리움 기본 - IPAM: 6

다른 글 보기

하위 문서

관련 문서

지식 문서, EXPLAIN

기타 문서

참고